home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9701 / 000026_owner-urn-ietf _Thu Jan 30 13:58:09 1997.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA07734 for urn-ietf-out; Thu, 30 Jan 1997 13:58:09 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA07727 for <urn-ietf@services.bunyip.com>; Thu, 30 Jan 1997 13:58:06 -0500
  3. Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA15648  (mail destined for urn-ietf@services.bunyip.com); Thu, 30 Jan 97 13:58:03 -0500
  5. Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id MAA06134; Thu, 30 Jan 1997 12:57:46 -0600 (CST)
  6. From: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
  7. Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id MAA27832; Thu, 30 Jan 1997 12:58:03 -0600 (CST)
  8. Date: Thu, 30 Jan 1997 12:58:03 -0600 (CST)
  9. Message-Id: <199701301858.MAA27832@void.ncsa.uiuc.edu>
  10. To: Ryan Moats <jayhawk@ds.internic.net>
  11. Cc: urn-ietf@bunyip.com
  12. Subject: [URN] Some good ideas coming out of the "relative..."  discussions...
  13. In-Reply-To: <32F0D01E.5E5D@ds.internic.net>
  14. References: <32F0D01E.5E5D@ds.internic.net>
  15. Sender: owner-urn-ietf@services.bunyip.com
  16. Precedence: bulk
  17. Reply-To: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
  18. Errors-To: owner-urn-ietf@bunyip.com
  19.  
  20. Ryan Moats writes:
  21.  > documented separately.  In the interim, namespace developers SHOULD NOT
  22.  > use an unecoded "/", but rather use %-encoding for "/" ("%2F").
  23.  
  24. Curious development.  
  25.  
  26. The whole reason I went along with the recent work (the NAPTR
  27. mechanism and the "urn:" prefix for subscheme with opaque strings) was
  28. that I could still see how the hierarchical path scheme could be
  29. deployed.
  30.  
  31. This requirement means that either all name spaces under "urn:" will
  32. be flat, or if a name space uses a hierarchy, it must use a different
  33. delimiter thus destroying the possibility of using relative URIs and
  34. getting scalable resolution without later creating new names for
  35. everything.
  36.  
  37. I object strongly.
  38.  
  39. Disallowing unenconded '/' can only serve the flat name spaces, which
  40. I believe are unscalable.  This does not serve the internet well.
  41.  
  42. Protecting the world from hierarchical name spaces because you don't
  43. understand how they work is unnecessarily over constraining.  Why not
  44. allow some name spaces to be hierarchical and see if the resolution
  45. services can make them work?  What harm is there in that?  If a name
  46. space fails, it fails.  Other name spaces will fail too - I believe
  47. the flat name spaces will fail.  I'm not opposed to allowing flat
  48. name spaces to try, however.
  49.  
  50. The only sensible proposal is to *allow* unencoded '/', with the
  51. warning that they must be used in conformance to the relative URI
  52. spec.  That's my final offer.
  53.  
  54. --
  55. Daniel LaLiberte (liberte@ncsa.uiuc.edu)
  56. National Center for Supercomputing Applications
  57. http://union.ncsa.uiuc.edu/~liberte/